home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13604 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.1 KB
  1. Path: user2.mnsinc.com!huang
  2. From: huang@mnsinc.com (Szu-Wen Huang)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.object,comp.software-eng
  4. Subject: Re: Portability of code & skills (Beware of "C" Hackers etc)
  5. Followup-To: comp.lang.c++,comp.lang.c,comp.object,comp.software-eng
  6. Date: 26 Mar 1996 01:41:34 GMT
  7. Organization: Monumental Network Systems
  8. Message-ID: <4j7i0e$b7k@news1.mnsinc.com>
  9. References: <4ikb6kINN1is@mayne.ugrad.cs.ubc.ca> <3150415E.6396@sdt.com> <4ip5om$s9@bughouse.imonics.com> <4isfcu$p09@news1.mnsinc.com> <4j6c48$4mr@bughouse.imonics.com>
  10. NNTP-Posting-Host: user.mnsinc.com
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Imonics Corporation (rcook@imonics.com) wrote:
  14.  
  15. : Well, you got the "mean" part right.  As for not being for non-experts,
  16. : there sure are a lot of people touting Unix as the only good
  17. : operating system for any purpose.  Sheesh.
  18.  
  19. That's of course absurd.  Unix is large and powerful, and obviously
  20. unsuitable for small systems.
  21.  
  22. : As for "necessity": it is not necessary to name the list files command "ls", 
  23. : the help function "man", the print function "lp", and the editor "vi".
  24. : It is not and was never necessary to limit options to single case-
  25. : sensitive letters so that you have to remember all the magic mumbles
  26. : to do your work.  It is not necessary to give "cute" names to things
  27. : (say, "set noclobber").  These things don't save enough space to be
  28. : worth mentioning, even on the old 8-bit machines.  I don't believe
  29. : that's why it was done; do you have any evidence?  Would it have
  30. : taxed those early systems if the "ls" command had been named, say,
  31. : "list"?  Or "dir"?
  32.  
  33. I can't say for sure what was the exact reason, but I would venture to
  34. guess that being shorter to type was probably more important than size.
  35. After all, directory entries probably occupy the same length anyway.
  36. The command line parameters are short for a good reason, though.  It
  37. makes them easy to parse (you can use a case statement instead of having
  38. to do a series of strcmp()), and lessens the overhead code.
  39.  
  40. : I think part of it is blindness -- I think those people honestly think
  41. : that, if an abbreviation is good enough for them, it is good enough for
  42. : everyone.  That's why the namespace for Unix commands is such a bloody
  43. : mess.  They couldn't even keep consistent within their own commands;
  44. : "cd" for "change directory", but "pwd" for "print working directory".
  45. : Well, is it a "directory" or a "working directory"?  Come to think of
  46. : it, when else is it ever called a working directory?
  47.  
  48. The working directory is where you are currently working :).
  49.  
  50. : But I really do think that most of it is fascination with the ultimate
  51. : video game.  Look at this neat thing I can do, all I have to enter
  52. : is "awk -syLgX -poop -l cfgfile".
  53.  
  54. I disagree.  As I pointed out above, single-letter options are efficient
  55. in terms of the code required to understand them.
  56.  
  57. : And, yeah, I can define aliases for commands as I want.  But it should
  58. : not be the purpose of aliases to bring order to the chaos.  And all the
  59. : documentation, such as it is, uses the obscure names for everything.
  60. : I'm sorry, but your argument that it was necessary on limited machines
  61. : doesn't hold water.  Can you come up with anything better?  
  62.  
  63. Remember you're talking about an OS designed almost 30 years ago.  If
  64. you were around for the Apple ][, you'll feel the squeeze memory places
  65. upon you.  While not always effective, a good programmer just consciously
  66. and unconsciously save space.  It's really only in the 80s that we had
  67. the luxury to say, "who cares, it's just a few more bytes".
  68.  
  69. : What I'm complaining about, in this particular paragraph, is your very
  70. : argument -- "when computers were smaller, this was necessary".  My point
  71. : is that it was never necessary to save microseconds in a piece of code
  72. : just before the system prompted the user for an answer to something.
  73.  
  74. The case you cite is clearly one where optimizations are a waste of
  75. time.  However, programming is largely a matter of habit, and good
  76. programmers pick up habits over time.  If that "optimization" was
  77. effortless to do, then there's no big deal, right?  If somebody looks
  78. over a piece of code and optimizes 2 instructions right before a
  79. prompt, that is not a programmer I wish to defend ;).
  80.  
  81. : I'm not talking about a general-purpose routine, or something in a loop,
  82. : but cases where people seem to worry about tiny performance issues
  83. : even while they're gathering requirements, before they have any notion
  84. : of whether or where performance problems will be.
  85.  
  86. Those are not engineers, then.  Engineers solve problems, but only
  87. when there is a problem, or at least when a problem is obviously
  88. imminent.  If it ain't broke, ... ;)
  89.  
  90. : That whole mindset of saving microseconds has been poor engineering since
  91. : at least my entry into programming, on F8s and Z80s, in 1977.  It's a
  92. : red herring, meant to justify poor engineering that hasn't been "necessary"
  93. : (at least) since 3rd-generation languages became common.
  94.  
  95. Hmm, as I said, more and more people profile before optimization.  Habits
  96. are not easy to break, but those who can't break bad habits are naturally
  97. selected for extinction.  Don't worry.  :)
  98.